1. Field of the Invention
The present invention relates to information handling systems and more particularly to providing Bluetooth support across multiple operating system partitions of an information handling system.
2. Description of the Related Art
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
It is often desirable to couple devices with an information handling system. One known method of coupling devices is via a Bluetooth type connection. Bluetooth is an industrial specification for creating wireless personal area networks (PANs). Bluetooth provides a method to connect and exchange information between devices such as information handling systems, mobile phones, printers, digital cameras and video game consoles via a secure, globally unlicensed short-range radio frequency. The Bluetooth specification is developed by the Bluetooth Special Interest Group
One issue of a Bluetooth type connection relates to pairing. Pairing is how two devices (e.g., a phone and a headset) associate themselves with one another to create a Bluetooth type connection. The two devices generate a shared secret code that is used for all future communication between the devices. When two devices are paired, the devices can be sure about the identity of the other party. Pairing usually occurs one time between two devices. After pairing, connections between the two devices are authenticated automatically. According to the Bluetooth specification, the shared secret code (or PIN) can be between 8 and 128 bits long.
FIG. 1, labeled Prior Art, shows a flow chart of a Bluetooth pairing operation. The Master device is typically the Bluetooth device installed in within an information handling system while the Slave device is typically a hard coded device such as a headset or mouse.
There are five phases of involved in a pairing operation. A public key exchange phase (Phase 1); an authentication Stage 1 phase (Phase 2); an authentication Stage 2 phase (Phase 3); a link key calculation phase (Phase 4); and, a link manager protocol (LMP) authentication and encryption phase (Phase 5). Phases 1, 3, 4 and 5 are the same for all protocols whereas phase 2 (Authentication Stage 1) may differ depending on the protocol used. The Bluetooth Simple Pairing Whitepaper (2006) published by the Bluetooth Special Interest Group discusses the Bluetooth pairing operation in more detail.
More specifically, when initiating a pairing operation, an initiating device 100 (Device A, the master device) and a non-initiating device 102 (Device B, the slave device) start in a standby mode 110, 112, respectively. The initiating device is for example a primary operating system of an information handling system. The non-initiating device 102 is for example a Bluetooth keyboard or mouse. The initiating device 100 initiates an inquiry at step 120 and the non-initiating device 102 performs an inquiry scan and generates a response at step 122. With the inquiry and the response, the initiating device 100 and the non-initiating device 102 exchange a public key.
Next, the initiating device selects a pseudo-random nonce value Ra at step 130 and the non-initiating device 102 selects a pseudo-random nonce value Rb at step 132. The nonce value Ra is a unique random value from the initiating device 100 and the nonce value Rb is a unique random value from the non-initiating device 102. Next, the initiating device 100 sets the nonce value Ra to 0 at step 134 and the non-initiating device 102 sets the nonce value Rb to 0 at step 136. The nonce values Ra and Rb are for example, 128 bit values.
Next, the non-initiating device 102 computers a commitment value Cb at step 140. This commitment value is provided to the initiating device 100, which in reply provides the non-initiating device 102 with the nonce value Na. The non-initiating device 102 then provides the nonce value Nb to the initiating device 100, which then confirms the commitment value Cb at step 142. Next, the initiating device 100 computes a confirmation value Va at step 150 and the non-initiating device computes a confirmation value Vb at step 152 and a user confirms whether the confirmation values Va and Vb are equal on each device. The commitment values Ca, Cb, Va and Vb may be for example 6 digit values.
Next, the initiating device 100 computes a new confirmation value Ea (i.e., a check value) and provides this value to the non-initiating device at step 160 and the non-initiating device 102 computes a new confirmation value Eb (i.e., a check value) at step 162. Next, the non-initiating device 102 checks the confirmation value Ea and provides the confirmation value Eb to the initiating device at step 164. Next, the initiating device 100 checks the confirmation value Eb at step 166.
If the confirmation values Ea and Eb match, then the initiating device 100 and the non-initiating device 102 perform a link key calculation (Lr) at step 170 and then set up an encrypted communication session at step 172.
When a Bluetooth pair is formed between an operating system (OS) of an information handling system and a Bluetooth (BT) device, the information handling system OS is treated as a unique BT device to establish the pairing.
According to the current pairing process if there is a secondary OS present on the same system then the secondary OS will not be able to pair with the Slave device that was already paired with the Primary OS. So, for example, if a secondary initiating device 180 attempts to communicate with the non-initiating device at step 182, another public key exchange would be initiated. Each OS is identified as a new device and the Bluetooth secret key associated between one operating system and Bluetooth device does not work on the other OS.
This situation can lead to a bad customer experience, especially if a user desires to use a Bluetooth device on more than one operating system shipped on the same information handling system. For example, if a user purchases a Bluetooth enabled headset for use with an information handling system that includes a main operating system partition as well as a MediaDirect operating system partition, the user might not be able to use the headset when the information handling system is operating in a MediaDirect partition, even if the same BT drivers are installed on that partition.
In certain information handling systems, this issue has been addressed by switching from a Host Controller Interface (HCI) mode of operation to a Human Interface Device (HID) mode of operation when a user boots into the secondary OS partition for MediaDirect. Thus, a customer can continue to use a Keyboard and Mouse as a conventional USB device. The HID mode of operation is a universal serial bus (USB) protocol used by conventional USB mice and keyboards, and implemented in the basic input output system (BIOS) of many information handling system motherboards. However, many Bluetooth enabled peripherals do not have the ability to store multiple pairing data for reasons of cost, power and implementation complexity.